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Most electronic voting systems today satisfy the basic requirements of privacy, unreusability, eligibility and 
fairness in a natural and rather straightforward way. However, receipt-freeness, incoercibility and universal ver- 
ifiability are much harder to implement and in many cases they require a large amount of computation and 
communication overhead. In this work, we propose a blockchain-based voting system which achieves all the 
properties expected from secure elections without requiring too much from the voter. Coercion resistance and 
receipt-freeness are ensured by means of a randomizer token — a tamper-resistance source of randomness which 
acts as a black box in constructing the ballot for the user. Universal verifiability is ensured by the append-only 


structure of the blockchain, thus minimizing the trust placed in election authorities. Additionally, tallying the 
votes has linear overhead, hence our system is scalable and practical for large scale elections. 


1. Introduction 


Voting is an essential part of any democratic society, delivering the 
will of people in a fair and trustworthy manner. Compared to traditional 
voting systems which have a large overhead in both time and money, 
electronic voting (e-voting) systems present an alternative that aims to 
be secure, efficient, convenient and less error-prone. However, e-voting 
systems introduce several concerns, the most important being the po- 
tential for large scale fraud and attacks on privacy. 

Existing electronic voting systems mainly fall in two categories [1]. 
In the first category one finds systems that use a private voting booth 
where voters can cast their ballots in private (eg. [2-4], to name a few). 
Assuming that it is difficult to tap the communication line between the 
voting booth and the collection server, coercion and vote selling can be 
prevented. These systems, however, are still not convenient, requiring 
the presence of a voter in a polling station as in traditional paper-ballot 
systems. Systems of the second category are internet-based. After an 
initial registration period, people can cast their votes from any loca- 
tion as long as there is internet access availability ([5-9]). They use a 
combination of cryptographic primitives and protocols, such as blind 
signatures, threshold cryptosystems, mix networks, homomorphic en- 
cryption, etc. to satisfy the properties expected from secure elections. 
While voting of this kind aims to increase user participation and make 
the whole process more efficient, it also carries with it the potential of 
abuse at a larger scale. 

A voting system is considered secure if it satisfies the following prop- 
erties: 
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Privacy: It should be impossible to link a vote to a voter. 
Completeness: All valid votes are counted correctly. 

Soundness: Invalid votes should be easy to detect and discard. 
Eligibility: Only legitimate voters should be able to take part in the 
election. 

Unreusability: Voters can vote only once, thus double-voting is pre- 
vented. 

Fairness: Early results should not be obtained, as they could influence 
the vote of the remaining voters. 


The basic requirements listed above are relatively easy to implement 
and are satisfied by most electronic voting systems. Hence, a lot of re- 
search has focused on providing a list of extended requirements that, if 
not satisfied, can undermine the election results. These include: 


e Universal verifiability: Anyone should be able to verify the fairness 
of the election and the correct computation of the final tally from 
submitted ballots. 

e Receipt-freeness: A voter neither obtains nor is able to construct a 
receipt on how she voted. This would also prevent vote selling. 

* Coercion-resistance: A voter cannot be coerced into casting a partic- 
ular vote as desired by a coercer. 


These last two properties are considered very crucial and must be 
addressed in a fair and democratic election process. While coercion and 
vote buying also occur in traditional voting systems, these threats are 
more dangerous in Internet voting schemes as an attacker may exercise 
influence and control at a larger scale [7]. 
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Coercion is a strong attack on privacy, in which an adversary may 
instruct voters to reveal their keys or vote in a particular way. On the 
other hand, a coercion-free system is one in which a voter deceives an 
adversary into believing she behaved as instructed. This implies receipt- 
freeness since a voting proof can be used as an avenue for coercion. From 
a usability point of view it is best if such a system does not demand any 
strategy on the voter side (e.g. lie, create fake credentials, etc.) 

Our work uses Bitcoin’s blockchain infrastructure to realize an e- 
voting system that satisfies the properties described above. Participants 
that use the blockchain network have a single view of all transactions, 
requiring no trust on any particular entity. Hence the blockchain may be 
used to provide verifiability which is at the heart of all voting systems, 
minimizing at the same time the trust placed in election authorities. 

Contributions: Compared to existing work, our system has a number 
of advantages that we highlight here: i) it is simple in the sense that all 
a voter has to do is vote; ii) the tallying overhead is linear, making this 
a scalable and practical system for large scale elections; iii) the system 
remains universally verifiable; iv) voter privacy is guaranteed; privacy 
only depends on the existence of simple anonymous channels where 
users can submit their votes, and v) the protocol ensures receipt freeness 
and coercion-resistance. 

It is important to note that coercion resistance (and by implica- 
tion receipt-freeness) can be achieved by our scheme without asking 
the voters to vote multiple times in order to cancel possibly coerced 
submitted votes ([6,7,10]), issue fake credentials ([7,8]), or rely on 
the existence of re-randomization networks and re-encryption mixes 
({7-9,11,12]). All we need to assume is that the attacker cannot in- 
fluence the randomness used by the voter to encrypt her vote or au- 
thenticate herself. This is achieved through the use of a randomizer 
token, a tamper resistant device that can be instantiated with simple 
smart cards or Trusted Platform Module (TPM) enabled devices. Coer- 
cion resistance is then possible because the randomness used in the cre- 
ation of a ballot is not under the control of the voter. Thus, the voter 
cannot use it to re-create a ballot and show how she voted nor can 
she be coerced to use specific randomness in order to have her vote 
tracked. 

Thus, our scheme does not demand any strategy on the voter side. 
The voter does not need to lie or produce fake credentials nor does she 
have to re-vote or deceive the coercer in any way. The voter simply has 
no way to prove how she voted. Additionally, the use of a blockchain 
as a public medium to post the ballots helps eliminate trust to election 
authorities with its built-in verifiability and integrity properties. 

Organization: The remainder of the paper is structured as fol- 
lows. In the next section we review related work on receipt freeness 
and coercion resistance with emphasis on blockchain voting schemes. 
Section 3 discusses our voting model and the assumptions we use 
throughout the paper, while Section 4 highlights the cryptographic 
primitives used in our proposal. In Section 5, we detail the voting sys- 
tem; its security and efficiency properties are analyzed in Section 6 and 
further discussed in Section 7. Finally, Section 8 concludes this 
work. 


2. Related work 


Electronic voting systems can be thought as end-to-end systems that 
consume voters’ encrypted ballots and produce a final tally along with 
a proof that the result of the election was computed correctly. Most vot- 
ing systems use a combination of blind signatures, mix networks and 
homomorphic encryption techniques. Voting schemes based on blind 
signatures are generally simple and more efficient since voters can have 
their ballots blindly signed by the election authority and then submit 
them through an anonymous channel. These systems, however, are not 
receipt-free since voters can use the blind factors in their ballots to prove 
how they voted. Alternatively, a coercer may dictate the factor to be 
used. Voting schemes based on mix or re-encryption networks are gen- 
erally less efficient due to the larger number of intermediate steps in- 
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volved, while systems based on homomorphic encryption require the 
cooperation of a set of trustworthy tallying authorities to produce the 
final result. 

As mentioned in the introduction one important requirement of e- 
voting systems is receipt-freeness. The concept was introduced in [13] to 
capture security against vote selling. In a receipt-free system, the voter 
should not be able to get or construct a receipt proving the contents of 
her vote. Yet an even more desirable property which implies receipt- 
freeness is coercion resistance. This concept was formalized in [7] by 
defining an adversary who can demand participants to vote in a specific 
way. The system was based on a credential mechanism in which a voter 
could cast more than one ballots under different (fake) credentials, thus 
making it hard for an adversary to tie a vote to a particular credential 
(voter’s key pair). Each ballot, however, had to go through a series of 
mixes to ensure coercion-resistance, causing the overhead for the tal- 
lying authorities to be quadratic in the number of votes. The Civitas 
[8] system is an enhancement of this idea. 

Another important property of voting systems is verifiability which 
is about ensuring that the outcome of the election reflects correctly the 
voter choices. In a verifiable system, anyone should be able to verify 
that submitted ballots are tallied correctly. A popular system Helios 
[6] is verifiable but it is not receipt-free. On the other hand systems 
like [7] and its variants that depend on the trustworthiness of the tal- 
liers are not really verifiable. Although a basic assumption in all works 
is that not all talliers can be corrupt, Yi and Okamoto [1] argue that a 
verifiable system should not be built on the existence of a trustworthy 
set of tallying authorities. 

The emergence of blockchains introduced a new way to construct 
systems which have less inherent security vulnerabilities. Blockchains 
act as distributed databases, where the complete set of data stored in 
the database is shared among all participants in the network. This con- 
cept is the basic element of the Bitcoin! protocol, the largest peer- 
to-peer payment system that was developed as an alternative to con- 
ventional, centralized money systems. Blockchains have already been 
used in voting systems to increase the level of transparency and ver- 
ifiability offered. However, many of these solutions fail to satisfy im- 
portant properties expected from secure election systems as explained 
below. 

In [14], a fund transfer system is developed based on Bitcoin trans- 
actions. Correct voter behavior is enforced through the use of deposits, 
however, malicious voters can still forfeit the voting process by refus- 
ing to cast their votes. Voting in this scheme is reduced to transferring 
funds, similar to lottery protocols, but applicability is limited to choos- 
ing between two candidates. 

A protocol based on the work of [5] and the use of blind signatures 
is developed in [15]. Anonymity is maintained through the use of PBCs 
(Prepaid Bitcoin Cards) which are given to voters after registration, how- 
ever the scheme lacks receipt-freeness. In [16], a blockchain-based vot- 
ing platform is proposed to conduct national elections. This system relies 
upon the existence of a trusted third party to hide the user’s vote from 
the election authorities, which negates any of the benefits introduced 
by the use of blockchains. 

Recently, a smart-contract voting system was proposed in [17]. A 
person’s vote is distributed among peers who must tally the votes sub- 
mitted to them using homomorphic encryption. However, the system 
does not guarantee fairness as dishonest peers may intentionally “drop” 
votes. Such behavior is only prevented by incentivizing users to be- 
have correctly, which does not necessarily mitigate malicious behav- 
ior. Boardroom voting based on smart contracts was described in [18]. 
Yet the protocol is not coercion resistant and is limited to elections with 
two options (yes/no). Another recent smart-contract based proposal was 
given in [19]. It is based on homomorphic encryption and the use of 


1 “Bitcoin: A peer-to-peer electronic cash 
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linkable ring signatures to provide a voting framework that is indepen- 
dent from the security and privacy features of the underlying blockchain 
platform. 

The works in [20] and [21] make direct use of the ZeroCoin [22] and 
ZeroCash [23] protocols developed to anonymize bitcoin transactions. 
Here one anonymous coin is basically exchanged for one vote. How- 
ever, while the latter protocols help ensure the anonymity of bitcoin 
transactions, they cannot be used for voting per se as the security re- 
quirements are different. For example, the commitments used to hide 
the coins in [22] and [23] can help break receipt-freeness in voting 
schemes when used “as is”. Hence the protocols [20] and [21] are not 
coercion-resistant. 

A number of commercial systems ([24,25]) have also been proposed 
that use the blockchain as a ballot box. Although these systems claim 
to achieve verifiability and accessibility, they suffer from other short- 
comings. In particular, [24] requires a trusted authority to ensure voter 
confidentiality and to hide the correspondence between the voter’s iden- 
tity and their voting key. In [25], voter anonymity is protected through 
the use of a mixing phase, yet no mechanism is anticipated to protect 
voters from coercion. 

In this work we develop a blockchain-based voting protocol that 
aims to remove dependence on trusted third parties or election authori- 
ties in tallying and publishing election results. Having an on-blockchain 
election system enables direct observation and verifiability of the out- 
come using available tools and scripts running on the blockchain. 
Our proposal combines the benefits of using blockchain technologies 
with a number of cryptographic tools such as Pedersen commitments 
and zkSNARKs to achieve the properties expected from secure elec- 
tions. Our tools and assumptions are described in the sections that 
follow. 


3. Model 


The main entities in our system are the voters V4, ... V, which partic- 
ipate in the election administered by a registration authority R. The 
role of R is mainly to authenticate voters, distribute secret creden- 
tials and post their public credentials in a blockchain B set up for vot- 
ing. Once users are registered they can participate in the election. The 
blockchain is used to provide universal verifiability. It is an append- 
only mechanism whose goal is to create a consistent view of the in- 
formation posted which, once posted, it cannot be removed. Finally, 
the tallying authority 7 is responsible for processing the submitted bal- 
lots and publish the final result. The role of T in our proposal is min- 
imal since its role can be assumed by any interested party, including 
the voters themselves. The registrar and the tallier(s) can also be part 
of the same authority, often described by the term election authority 
(EA). 


3.1. Definition of voting scheme 


Voting in our system consists of each voter submitting a single vote 
y which captures the choices of the election (e.g. whether there is one or 
many candidates, whether the vote is a simple ‘Yes’ or ‘No’, and so on). 
We abstract away these details under the submission of a vote v whose 
format is well specified by the election authority £A. Any invalid votes 
will be rejected during tallying. 

The main operations of our proposal are listed below. These enable 
users to register, vote, verify the tally, and so on. Each voter carries a 
token randomizer (defined in the next section) that helps her with some 
of these tasks. 


* Setup(1*) > params is a probabilistic algorithm that on input a secu- 
rity parameter x generates the election authority’s public and private 
keys along with other system parameters. 

* Register(V7,,R) > (Vi, Ci, o;) is a protocol executed between a voter 
V, and the registrar R. The outcome of this protocol is a pair of pub- 
lic/private keys for the voter along with a signed commitment G; 


Computer Networks 174 (2020) 107234 


on values s;, r; generated and kept secret by V,’s token randomizer. 
These values will later be used in the voting phase to ensure eligibil- 
ity and prevent double-voting. The commitment is signed with the 
voter’s private key to produce o;. Once this phase is over, the voter 
is authorized to vote and (V;, C;, o;) is made public (can be posted in 
the blockchain or more simply be listed in the registrar’s web page). 
This operation does not require an anonymous channel. 
Vote(params, V;, 8;,1;,U;, K;) > b; is executed by V;’s randomizer to 
produce ballot b;. At a high level, V, constructs a vote v; and then 
encrypts it with a one-time key K; to produce Ex (v). She then reveals 
s; and produces a proof z; that she knows the secret number r; used in 
the commitment C;, without however revealing either of r; or C;. The 
ballot b; = (z;, s;, Ex,(v)) is then sent to the blockchain 8 through an 
anonymous channel. 

Valid(params, B, b) > {L, T} checks the validity of a ballot b posted 
on the blockchain B. It returns T for valid ballots and L for invalid 
ones (e.g. containing proofs that fail to verify, containing numbers s 
that have already been posted in the blockchain, and so on). 
PostKey(V;) > (s;, K;) is used by voter V, to anonymously post her key 
K; in the blockchain, while s; is also sent to facilitate matching the 
key to her previously transmitted encrypted vote Ex, (v;). 
Tally(7, B, {b;};, {K;};) > 7 is run by talliers 7 to produce the final 
election result. The talliers apply Valid(params, B, b;) to check the va- 
lidity of ballots b; and use the keys to decrypt the votes and account 
them in the tally r. 

VerifyTally(B, {b;};,{K;};,7) > {1,T} is used to check the election 
tally t. Any interested party (the public, the voters, etc.) can verify 
if each ballot carries a correct proof, and if each encrypted vote has 
been decrypted and incorporated only once in the final tally. If the 
result equals z, the function outputs T, otherwise it outputs L. 


Our voting scheme VS is the collection of the functions 
defined above and is denoted as VS = {Setup, Register, Vote, 
Valid, PostKey, Tally, VerifyTally }. 


3.2. Assumptions 


3.2.1. Election authorities and setup 

Our voting scheme places minimal trust in election authorities in 
the sense that they can collaborate with each other to reveal a per- 
son’s vote. For example a registrar R can leak to an adversary infor- 
mation revealed during the registration process as an attempt to infer 
the vote of a user. Alternatively, an adversary may coerce a voter to 
retain transcripts of the registration process. Similarly, talliers can col- 
laborate with R to modify or miscount votes. Our protocol is resistant to 
these adversarial behaviors. However, we must assume the following op- 
erational assumption regarding token randomizers (described in detail 
below): 


e OA-1: Token randomizers handed to the users by the election au- 
thorities are not malicious and can be trusted. This is similar to the 
issuance of smart cards to be used in e-voting schemes for secure 
identification, secure storage and for processing parts of the e-voting 
scheme such as signing and encrypting messages and/or votes [26]. 
We thus take it as given that independent verification and analy- 
sis can vouch for the correct operation and trustworthiness of the 
randomizers. 


Additionally, the zkSNARKs (see Section 4) require a trusted party to 
generate the common reference string (CRS) for the production and the 
verification of the proofs. However, a malicious party (e.g. the election 
authorities) can provide a CRS that allows it to break the ZK property 
and learn information about the voter’s secret parameters. This attack 
can be prevented if the prover (voter) checks that the CRS is correctly 
formed. Hence no trust is really placed on the election authorities. Alter- 
natively, the use of Subversion-NIZK [27] ensures that the ZK property 
is preserved even under maliciously chosen CRS. 
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3.2.2. Coercion-resistance and token randomizer properties 

Coercion can come in many flavors, from simple, the coercer is- 
sues some instructions and asks for a proof, to full-on: the coercer is 
with the voter to make sure that she makes the right voting decisions 
(e.g. the coercer might be watching through an online video feed). 
Defending against the latter case is clearly impossible. Our goal is to 
produce an election scheme that mitigates threats of the former case, 
while satisfying secure election requirements with as few assumptions as 
possible. 

In this work we introduce the notion of a token randomizer (TR), a 
tamper-resistant device which acts as a black-box on behalf of the user. 
Receipt-freeness and coercion resistance now will be based on the dif- 
ficulty of tampering with TR, in particular disclosing randomness pro- 
duced internally. Randomization services are not new in the literature 
of e-voting. They go as back as [28], in which the authors proposed a 
receipt-free voting scheme based on a trusted, third-party randomizer, 
and [29-31] in which the role of the external randomizer is assumed by 
a tamper-resistant device. Despite the use of such device, however, these 
voting protocols remain rather involved, requiring the use of threshold 
cryptosystems and trustful talliers. 

Here, our expectations from the 7R are much simpler. Below we 
list the main assumptions and operations we anticipate from such token 
randomizer. 


* TRA-1: TR is programmed in advance to perform certain crypto- 
graphic operations on data submitted to it through pre-defined API 
calls. Additionally, TR has its own source of randomness which 
can be used to generate cryptographic keys or other random val- 
ues required by 7R’s built-in logic. Such randomness is retained 
with the 7R’s module and is safely erased once it is not needed 
any more for subsequent operations. However, the 7R may return 
such data to higher level programs if this is dictated by its pre- 
defined logic. Thus, the user does not have access to 7R’s state 
unless otherwise specified by the algorithms “hardwired” in the 
TR. 

TRA-2: TR may internally store values which can be returned to the 
user once a predefined interval has passed. This assumes the exis- 
tence of an internal counter that can be used to release information 
at selected intervals only. These intervals are also hardwired in the 
TR before the election starts and cannot be modified at will. 


The first assumption, TRA-1, is typical of tamper-resistant devices 
such as smart cards or TPM-enabled chips. As far as we know, there is 
also nothing to prevent the feasibility of TRA-2. The logic of TR will be 
captured by the following operations. 


* TR.Commit() > C. The randomizer returns a Pedersen (Section 4) 
commitment C = g% modp for values s and r chosen at random by 
TR. Only C is returned to the user while both r and s are stored 
internally. 

TR .Ballot(v) > {(s, Ex(v), z), L}. The randomizer creates a one-time 
key K and uses it to encrypt the vote v supplied as input by the 
user. Embedded in its logic is the proof system of the zkSNARK gen- 
erator (Section 4) which uses only public information and the ran- 
domness r retained by TR to compute a zero knowledge proof of 
knowledge for the value r used in the commitment C. Once z is com- 
puted, r is permanently destroyed. The randomizer posts the tuple 
(s, Ex(v), x) to the blockchain but stores K internally. Subsequent 
calls of TR.Ballot(v) will return the value L as r has been erased. 
Additionally, premature calls of this function (i.e. before the inter- 
nal counter reaches the correct value signifying the beginning of the 
voting period) also return the value L. 

TR Reveal() > {(s, K}, L}. Once the internal clock of the randomizer 
reaches the correct value, signifying the end of the voting period, it 
posts to the blockchain the value s and the key K used in the encryp- 
tion Ex(v) of the vote. Then s, K are permanently destroyed. Prema- 
ture calls of this function return the value L as well as subsequent 
ones. 
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The intervals used in the 7R.Ballot and 7R.Reveal operations are 
embedded in its logic and cannot change at election time. These val- 
ues have been specified by the election authorities in advance. Fi- 
nally, the randomizer is presented to the user by the registrar R. 
All messages produced by the 7R are digitally signed with its Direct 
Anonymous Attestation? (DAA) signing key. Messages posted to the 
blockchain must bear the DAA-signature of the TR to be considered 
valid. 

As mentioned in the beginning of the section, we assume that inde- 
pendent verification and analysis can verify the correct operation of the 
randomizer. 


Remark 1. There is an obvious attack that can be used to break 
coercion-resistance of the system; the user may be forced to simply hand- 
over its token randomizer. In Section 6.1.2, we explain how the basic 
functionalities of TR can be extended to defend against this type of 
attack. 


3.2.3. Need for anonymous communications 
Finally, we add another operational assumption on the existence 
anonymous channels. 


e OA-2: Ballots must be casted through anonymous communication 
channels since if the IP address of the voter/7 R is visible when she 
casts a vote then it can be easily linked to the identity submitted 
during the registration phase. We further assume that ballots cannot 
be distinguished based on side channels like time of submission that 
can lead to timing attacks. 


The use of anonymous channels such as those implied by TOR is 
a standard assumption in all works where users interact directly with 
an adversarial authority. Hence we do not consider this a strong as- 
sumption. Perhaps less obvious is the absence of timing attacks that 
can be used to compromise vote privacy by linking the time the bal- 
lot is submitted to the time the ballot is received. If this difference 
is small then disambiguation is possible. However, as the interval be- 
tween posting a transaction to the P2P blockchain network and see- 
ing the transaction stored in some block may be large, we believe 
this is a reasonable assumption to expect, especially for large scale 
elections. 

A complete solution to the problem would require the use of mix net- 
works [33] to shuffle the ballots and enforce sender-receiver unlinkabil- 
ity. This solution can also be applied in our case, however we feel that 
this is not necessary; to further reduce the risk of timing attacks, we can 
slightly extend the capabilities of the 7R by either (i) having 7 Rs sub- 
mit additional, fake/garbage ballots at random intervals that will hide 
the real ballot submitted, or (ii) having 7Rs submit their unique ballot 
at fixed intervals which are uniform across all randomizers. The first ap- 
proach is easy to implement and fake ballots can easily be filtered even if 
stored in the blockchain, while the second will only require the random- 
izer to store the ballot until the predefined interval/counter is reached. 
Both solutions would result in increasing the size of the anonymity set, 


2 In the context of vote submission, our goal is to be able to verify that a 
submitted ballot or key is authenticated but without tying it to a particular 
randomizer device. For completeness, we briefly summarize how DAA can be 
adopted in this setting; the interested reader may look at how the scheme has 
been used for remote, anonymous authentication of Trusted Platform Modules 
(TPMs) [32]. In our setting the DAA signer is the token randomizer/TPM, a 
DAA issuer is the manufacturer of the randomizers, while a verifier can be the 
election authorities or any other external party. At the core of the scheme is the 
certification of the DAA key by the issuer, which however learns nothing about 
the key. Signing with such a key provides anonymity-preserving assurance that 
the randomizer has a valid DAA key. Yet, neither the verifier nor the issuer, even 
if they collude with each other, can tell which randomizer signed a message, 
only that the signature comes from a valid randomizer. In short, the TPM can 
transform the original credential into new a credential that cannot be linked to 
original one. The reader may consult [32] for more explanations. 
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thus making it hard for an adversary to link a submitted ballot to a re- 
ceived one. 

Finally, we do not consider Denial-of-Service (DoS) attacks in this 
work. As the network is open, malicious users may attempt to flood the 
network with invalid data but again such erroneous data can easily be 
filtered. Alternatively, to avoid machine generated posts, users may re- 
quired to solve a CAPTCHA or, as proposed in [7], solve a cryptographic 
puzzle before submitting their vote; however this is beyond the scope of 
this work. 


4. Main tools 


In what follows we describe the main tools we will be using in our 
proposal. We assume the existence of two groups G = (g) and G = (g) of 
prime order q = O(2*), with x being the security parameter, that have 
an efficiently computable bilinear pairing e. 


Pedersen commitments 

A commitment scheme is a pair of algorithms (Commit, Open) ex- 
ecuted between a committer and a receiver. Commit takes a mes- 
sage m and a random number r, and produces a commitment C = 
Commit(m, r). In the opening phase, the committer sends (m, r) to the 
receiver which checks whether the opening algorithm Open(C, m, r) re- 
turns Accept. A commitment scheme is secure if it is both binding and 
hiding. The “hiding” property ensures that the receiver can learn no 
information about m before the opening phase, while the “binding” 
property ensures that, once committed, a malicious user cannot find 
different m’ or r’ such that Open(C, m’, r’) = Accept. The Pedersen com- 
mitment scheme can be used to commit to a message m by computing 
Commit(m, r) = h’8" modq, where g is a generator of a group G of prime 
order q. 


QAPs and zkSNARKs 

We will base our constructions to the zero-knowledge Succinct Non- 
interactive ARguments of Knowledge (zkSNARKs) as developed in [35]. 
Such arguments can be used to prove NP statements about Quadratics 
Arithmetic Programs (QAPs) without revealing anything about the cor- 
responding witnesses. After taking a QAP Q as input, a one-time setup 
results in two public keys: an evaluation key EKg and a verification key 
EVg. The evaluation key allows an untrusted prover to produce a proof 
x regarding the validity of the QAP NP statement. The non-interactive 
proof is a zero knowledge proof of knowledge, thus anyone can use the 
verification key to verify the proof z. In our setting, the use of zkSNARKs 
will be used to guarantee that a voter is eligible to vote and cannot be 
de-anonymized. 

Informally, a zkSNARK for a QAP Q is a triple of (randomized) algo- 
rithms (KeyGen, Compute, Verify): 


+ KeyGen(Q, 1“) > (EKg,V Kg). On input a security parameter 1* and 
a QAP Q, this function produces a public evaluation key EKg and a 
public verification key VKg. 

+ Compute(E Kg, x, w) > ag. On input a public evaluation key EKo, a 
x € Lg, where Lg is the NP decision language defined by the QAP, 
and a corresponding witness w, this function produces a proof zg 
that w is a valid witness for x. 

° Verify(V Kg, x, ag) > {0,1}. On input a public verification key VKo 
x and a proof zo, it outputs 1 if x € Lg and 0 otherwise. 


The properties expected by zkSNARKs are completeness, soundness 
and zero knowledge. The proof returned by algorithm Compute can be 
turned into a signature scheme by making the message m to be signed 
part of the challenges exchanged while constructing the proof [37]. We 
will denote this by the notation 


zo + ZkSNARK[m]((S) : P), 


where S insides parentheses denotes private information known only 
to the prover while P constitutes public information available to the 
verifier. 
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Let d be the degree of the QAP and let q = 4d + 4. In terms of security, 
the constructions above are secure under the q-power knowledge of ex- 
ponent (d-PKE), the q-power Diffie-Hellman (q-PDH) and the 2q-strong 
Diffie-Hellman (2q-SDH) assumptions [35]. 


Blockchains 

We assume limited familiarity with Bitcoin and blockchains, for more 
information the reader is referred to [38]. A blockchain is a linked-list 
data structure in which data is organized as blocks, and blocks are con- 
nected together through hash pointers (pointer to the hash value of the 
previous block) to form a chain. Maintaining a hash pointer instead of a 
simple pointer turns the blockchain into an append-only data structure. 
As all nodes point to the hash of the previous node, updating a node will 
result in a chain of updates all the way until the first node in the list. 
Thus any change to an earlier node can be detected by maintaining the 
first node’s hash value. This property allows the blockchain to maintain 
its integrity. 

The process of extending the blockchain is called mining. Miners 
compete against each other to extend the blockchain with new blocks. 
This competition ensures that the network always maintains the largest 
chain through appropriate consensus mechanisms such as proof-of-work 
or proof-of-stake. As a result, a nodes’ dishonest behavior will be de- 
tected and prevented by other nodes. 

In this work, we envision the use of the blockchain as a substitute 
to a public board that should be secure, anonymous and transparent. In 
the proposed system, the trust to other authorities will be minimized. 
This way, authorities cannot perform malicious actions because trans- 
actions are communicated in public and the append-only character of 
the blockchain ensures that all transactions are being considered. For 
more information on blockchains and their use for voting, please see 
Section 7. 


5. Voting protocol 


The protocol works in a P2P, distributed fashion without the need 
of centralized server. There is a one-time setup phase for the zkSNARK 
algorithms which can be used for multiple elections. 

Before we delve into the details of the protocol, we give a rough 
outline of the main phases of our voting scheme (see also Fig. 1). 
During an initial registration phase, each user is equipped with a to- 
ken randomizer and public-private key pair which will be used to 
sign a commitment during the pre-voting period. This commitment, 
along with the user ID and signature will signal the legitimacy of the 
voter to participate in the voting process. The randomizer will be re- 
sponsible for carrying out the main voting actions on behalf of the 
voter. 

During the actual voting period, a registered voter can cast an en- 
crypted vote, authenticating herself using a zkSNARK proof z con- 
structed with the previously submitted commitment. Essentially the 
voter proves in z that she knows the secret values bound in one of the 
commitments submitted by voters in the previous phase. When the vot- 
ing phase is over, voters will submit the key K used to encrypt their 
vote. Using these keys, votes can be decrypted and counting can take 
place. Auditing and verification can be done by any interested party 
once the counting phase is over. The details of each phase are shown in 
the sections that follow. 

Finally, the authorities define a list of intervals to ensure that the 
election progresses in a timely manner. 


e Tyoting: This signifies the most important phase of the election in 
which voters submit their ballots. 

* Tposevoting: At this point no more ballots will be accepted by the sys- 
tem. When this phase begins, voters submit the keys used to encrypt 
their votes. 

* Trattying: The election is over and tallying can begin. 


T. Dimitriou 


Timeli a 
jh a rd aoe Election Authority 
(Registration (PK) #RTR EN 
TR.Commit() (Cj, 0) 
i TR.Ballot(v) (SEx(Y),™) O yŤý 2 
| Post-Voting} T R.Reveal() (s, K) 


| a en os > 


Tallying Auditing and verification Fa 


These intervals must be active for a sufficient amount of time to allow 
voters to commit and cast their votes. These timers are embedded in the 
token randomizers as explained below. 


5.1. One-time setup 


The system is initialized with a call to KeyGen(1*), where «x is the 
security parameter. Once the group parameters (q, G, G, g, g, e) are 
created, the election authority picks a public/private key pair that will 
be used to sign voters’ public keys during registration. 


5.2. Pre-Registration and preparations 


To participate in the election, users must register first. This typically 
occurs by presenting valid credentials such as a national ID or passport. 
Additionally the voter generates a public/private key pair (PK; SK;) and 
submits her public key to be signed by the registration authority. The 
authenticated public key will be included in the list of eligible voters 
along with the user ID. 

Each voter is then presented with a token randomizer whose role is 
to facilitate the rest of the phases of the election. Timer Tyoring is associ- 
ated with operation 7 R .Ballot(), preventing voters to have access or cast 
their ballots before time Tyoring. Similarly, Tpostvoting is associated with 
TR Reveal() which is used to post the ballot keys to the blockchain. 


5.3. Registration 


Register(V;, R) is executed between a voter V, and the registrar R. 
Every pre-registered user who wishes to participate in the election will 
send to the registrar a commitment C; + 7R;.Commit() for a secret value 
s; masked with a random value r; to be used in the actual voting pro- 
cess. The voter does not have access to the values s;, r; which constitute 
internal state of her TR;. 

The commitment is then signed by V, using her private key SK; 
to produce a signature o; on C;. An entry (V,,C;,o;) will be created 
by R and posted in the blockchain or in a public database which 
will hold these triples for all legitimate voters and their commitments. 
Legitimacy of the signed commitment can be verified by checking 
whether the associated public key belongs to one of the voters that 
have been certified. It is clear that submission of the pair (C, o;) 
does not have to be anonymous. These values should be verifiable 
by any entity for the sake of transparency and validity of the voting 
process. 

Notice that while the pre-registration and registration periods have 
been described as two separate phases, they can also be merged to one 
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Fig. 1. Voting phases. Dotted lines indicate use of anonymous 
channels. 


Blockchain network 


if voters already possess valid credentials. These preparations usually 
take place before the actual voting to give enough time to users to fulfill 
the necessary election requirements. 


5.4. Voting period 


A registered voter V uses Vote(params, V, s,r, v, K) to anonymously 
cast a ballot b, authenticating herself as a legitimate voter using a zk- 
SNARK. In this phase, each voter reveals the secret number s used in her 
commitment C and proves knowledge of the secret value r used. The re- 
lease of s prevents double-voting, since s is stored in the blockchain and 
cannot be re-used. The whole process is facilitated by the voter’s TR. 
The exacts details are described below. 

The zkSNARK is constructed by the 7R, making use of the pairing 
system developed in [35,36] which encodes computations as QAPs. The 
quadratic program for vote submission is based on the following two 
observations: 


e Checking whether a commitment C belongs to the set of commit- 
ments {Cp,C),...,C,_,} submitted by voters is equivalent to check- 
ing whether IT,(C — C;) = 0. 

To prove knowledge of r in the commitment C = g'h”, one can ar- 
gue as follows. Let r=r,_)2"~!+--+2r; +ro be the binary rep- 
resentation of r, with x being the security parameter of the com- 
mitment scheme. Then C = g°h"«-12"!+-+#2r1+70 = ee h'i” . Thus, 
instead of proving knowledge of r, one can prove knowledge of 
ho, hy, ..., Ag, with hj being equal to 1 or h”, depending on the 
value of bit rj, such that C = gT hj. 


Combining the two requirements, we obtain the following witness 
relation R that can be captured by a QAP: 


(Co Cis Cuts (had) eRe 


Vi(hy = (hy = h”) = 0 A TE TSh; 


-C) =0 

To vote, the user makes a call 7 R.Ballot(v) to its token randomizer, 
where v captures the user’s choice. The randomizer picks a fresh key K 
to produce Ex(v). It also computes g° and h; = h’i?’, where r = È; rð, 
This is possible since s and r have been stored internally in the TR. Then 
it feeds these values to the proof algorithm (recall Section 4) which is 
again part of the TR to get z = Compute((Cp, Cj, ... > Cri 8°, (h)Z). 
This proof is essentially a signature for the encrypted vote by including 
Ex(y) to the random values used by the prover. Thus, TR creates a ballot 
which consists of the encryption of the vote E,(v), the number s and the 
proof 


z = zkSNARKĻ E K Ch) | CCN) 
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where the h;’s are part of the internal state of the TR. Once the proof is 
created, rand the hs are permanently erased. The key K and s, however, 
are retained until the next phase. Finally, the ballot 


b = (s, Eg (v), 2} 


is posted anonymously to the blockchain. 
5.5. Post-voting 


When the election authorities signal the end of the voting period, no 
more encrypted votes will be accepted and voters can release the keys 
used to encrypt their votes. Notice that for some elections it might be 
ok for the vote to be unencrypted and counting to begin as soon as the 
votes arrive. In that case the proof z above would just contain the user’s 
vote v in plain form. 

However, this would expose the progress of the election while 
still in the voting phase. In most election systems this would violate 
the fairness property as early results may influence the decision of 
late voters. Hence the need for the encrypted vote. Encryption keys 
are posted to the blockchain through calls to PostKey(V;), which is 
making use of the voter’s randomizer functionality 7 R.Reveal(). The 
pair (s, K) is again posted to the blockchain through an anonymous 
channel. 


5.6. Tallying and Verifying 


Once the key-submission phase is over, keys will be matched to 
encrypted votes and counting can begin using Tally(7, B, {b;};, {K;};)- 
This phase is straightforward as all the information is available in the 
blockchain and can be carried out by the talliers 7 or any other in- 
terested party. Hence anybody can audit and verify the tally r using 
VerifyTally(B, {b; };, {K; }p T). 

To facilitate decryption, the talliers may store encrypted votes in a 
hashtable as soon as they are posted. The key to search the hashtable is 
the value s contained in the ballot and sent along with the key. Thus, 
keys and encrypted votes can be matched easily, so decryption takes 
O(1) per vote, or O(n) overall. 


6. Analysis 


In this section we analyze the security and efficiency aspects of our 
proposal, with emphasis on coercion resistance. 


6.1. Security 


Eligibility: IDs of registered voters are published together with their 
commitments C;. When voters obtain their randomizers 7R,, election 
authorities know that submitted ballots are authorized although they 
cannot link a ballot to a voter. Therefore only legitimate voters can par- 
ticipate in voting. 

Unreusability: Each voter, by means of its randomizer, posts an en- 
crypted ballot which is tied to one of the commitments through the asso- 
ciated zkSNARK and the serial s; used in C;. Double voting is prevented 
since no second vote can be submitted with the same s;. Thus, every 
voter can only vote once. 

Universal Verifiability, Completeness and Soundness: Our protocol pro- 
vides universal verifiability since both the outcome of the election and 
the submitted ballots can easily be checked by any other interested 
party. In particular, one can 


e Check that all submitted commitments C; have been properly signed 
by certified voter keys. 

e Verify whether the zkSNARKs in submitted ballots b; are prop- 
erly constructed. These proofs essentially show that they have been 
posted by a legitimate voter, who has submitted a commitment in 
the previous phase and can be accounted only once (through their 
serial number s;). 
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e Match they keys to encrypted votes using the serials s;. 
e Recount the decrypted votes using VerifyTally(3, {b;},, {Kj}, T). 


Thus, if these checks are performed, one can be sure that all ballots 
posted on the blockchain are correctly tallied and accounted in the fi- 
nal result. Hence the protocol has completeness. As invalid ballots are 
discarded and not considered in the tally, the protocol also satisfies the 
soundness property. 


6.1.1. Receipt-freeness and Coercion-resistance: 

In this work we are assuming that the attacker cannot constantly 
monitor the voter. Making a system resistant to this type of attack 
is impossible if the coercer and the voter are side-by-side during the 
whole voting period. Note that re-voting does not solve this prob- 
lem as this assumes that the voter is given a chance to vote again 
in private. Our work considers attackers that will issue instructions 
and ask for proof of compliance. Matching these instructions to some 
form of receipt is the only way for the coercer to check if a voter has 
complied. 

Typically, these instructions may require the voter to use a specific 
encryption key or randomness that may link the outcome of a crypto- 
graphic operation to the coerced vote. In our case, the only places where 
this can occur is (i) during registration, in the construction of the initial 
commitment C, and (ii) during voting, in the encryption of the vote with 
the one-time key K. 

The randomness r used in the commitment C = h"g’ is never re- 
vealed by the randomizer and is safely erased once the proof m is 
constructed during the operation 7R.Ballot(v). Assuming the tamper- 
resistance of randomizer 7R, the voter cannot obtain any informa- 
tion on 7R’s internal state (r and K). As the voter cannot prove any 
correlation between the submitted ballot (voting phase) and the com- 
mitment (registration), no receipt can constructed from the protocol 
messages. These observations will be captured by the model defined 
below. 


Remark 2. Note that a coerced voter may try to submit an invalid vote. 
Although this would reveal the link between the vote and the voter upon 
decryption, such a vote would not be useful to the coercer. This “attack” 
can be prevented by making sure that only well-constructed votes are 
posted by the randomizer during operation 7 R .Ballot(v). 


Remark 3. A voter may try to sell her vote by bypassing TR en- 
tirely. The voter may generate the commitment herself and submit 
the zkSNARK proof during voting. This would definitely be possi- 
ble since 7R only uses public algorithms to construct the proof. 
However, any submission during the voting phase must bear the 
DAA-signature of a registered TR. The tamper-resistance of the TR 
ensures that a voter does not have access to the embedded DAA 
key. 


To model coercion, we follow the definition of privacy introduced 
in recent works [12,34]. These works are mostly used to model proto- 
cols where the tally does not produce just a result but also proofs of 
correct tallying (in our case, tallying is just plain counting of votes). 
Coercion is formalized as a game in which an adversary A has to distin- 
guish between two worlds: one in which coercion succeeds and one in 
which it doesn’t. In both worlds, all information submitted is contained 
in ballot boxes BBy and BB, that start out empty. Box BBy corresponds 
to the real election (that will be tallied) while BB, is a fake ballot box 
which the adversary has to distinguish from BBy. In both worlds, the ad- 
versary can see the information posted in the ballot boxes BB p where 
p= {0,1}. 

Using this definition our scheme would be deemed insecure since 
an adversary could easily distinguish between the two cases using the 
encryption keys posted in the blockchain. Yet these keys have only been 
used to introduce fairness to the election so that votes are not visible 
prematurely. They do not present any new information to an observer, 
so they should not be used to judge privacy. Additionally, using these 
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Experiment Exp E g 


Setup phase: The system is initialized with a call to 
KeyGen(1"), where « is the security parameter. A set 
Y of n voters is registered into the system. Each voter 
V; generates a key pair (PK;, SK;) and is given a ran- 
domizer 7 R; which is used to produce a commitment 
Ci 4 TR;.Commit(). Commitments are signed by the 
voters. The collection of signed commitments {(C;, oi) }i 
is given to adversary A. 


Challenge phase: 


e A selects two voters Vo and VY, and a vote v. A is 
given access to a voting oracle. 


ope {0,1}. The oracle gives A the ballot bg which 
is equal to (sg, Eg, (v), ng) <— T Rg.Ballot(v). 


e A outputs a guess bit 6’. 


Exp is successful if 8 = p’. 


crp 


Fig. 2. Coercion-resistance experiment Exp% y s- 


models, one has to make certain assumptions about the distribution of 
votes (as in [1,7]) in order to preclude trivial distinguishing attacks such 
as when honest nodes vote for candidates a and b but the coerced voter 
votes for c. 

To show that our system is coercion-free, we use the experiment 
shown in Fig. 2 that closely matches the workings of our protocol. In 
this setting, voters participating in the voting system VS interact with 
an adversary A. In particular, two voters V), V, are involved in the fol- 
lowing game with A. After the voters are registered, they are “coerced” 
to create a ballot by = (sp Ex,(v), 7) < TR, Ballot(v), for a vote v cho- 
sen by A and £ = 0, 1. The adversary is then given access to one of the 
ballots and is asked to guess which voter does it correspond to. A wins 
the game if its guess is correct. 

If the adversary cannot distinguish the two cases with probability 
significantly more than random guessing, we say that the scheme pro- 
vides coercion-resistance as per the definition below: 


Definition 1 (CR). Let VS = {Setup, Register, Vote, Valid, PostKey, 
Tally, Verify- Tally} be our voting scheme. We say that VS is coercion- 
resistant if no PPT adversary A can distinguish between the games 
Exp, ș and Exp 5 defined by the experiment in Fig. 2; that is, for 
any PPT adversary A the following is negligible in the security param- 


eter K: 


Pr [Exp s = 1| —Pr [Expt s = 1| | 


We now show that our voting system is coercion-resistant. 


Theorem 1. Our voting system VS is coercion-resistant if the commitment 
scheme is hiding and the QAP proof system is sound and zero knowledge. 


Proof. We prove the theorem by showing that from an adversary A that 
attacks coercion-resistance we can construct adversaries 8 and C against 
the commitment scheme and the QAP proof system such that 


cr hide pok—extr ZK 
Adv" ys < Adv + AdvpoK € + Adviok.c? 


where Adyhide denotes the hiding advantage of the commitment scheme 
and Adv? a AdvŽý, „ the extractability and zero-knowledge advan- 


tages of the underlying ZkSNARK system, respectively. 
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For the setup phase described in Fig. 2, coercion-resistance reduces 
to the Discrete Log (DL) assumption used to prove the hiding property 
of the commitment scheme as no polynomial time algorithm can distin- 
guish between A's’ modq and another random quantity t € Z,, If there 
is a polynomial time adversary A that breaks coercion-resistance in our 
voting scheme then that adversary could be used by an adversary B to 
determine if its input is a Pedersen commitment in polynomial time. 
This would break the DL assumption of the commitment scheme. 

Alternatively, an adversary A may try to break the soundness 
property of the underlying zkSNARK. A can try to extract a wit- 
ness from all verifying proofs of knowledge zg = Compute((Co, C1, ..., 
Cy g”, (Aji) communicated during the challenge phase. If A can 
do this, then it can guess the bit J used in the experiment of Fig. 2. 
However, the success of A depends on the outcome of an extrac- 
tor algorithm E for the QAP system whose advantage is bounded by 
Ady kext, 

POK,C 

Finally, A may try to break the zero knowledge property of the asso- 
ciated zkSNARK. A SNARK for an NP language L with a corresponding 
NP relation R is zero-knowledge, if there exists a simulator S that can 
produce a simulated proof that is indistinguishable from the the real 
proof z [37]. This property guarantees that the proof reveals nothing 
more than the correctness of the statement. Thus, an adversary A that 
breaks coercion-resistance in our voting scheme implies an adversary C 
that breaks the zero-knowledge property of the NIZK proof system with 
advantage Advigk.c: 

Adversary C works as follows. It runs adversary A as a subroutine 
by simulating the security experiment exactly as in Fig. 2. When C has 
to decide between a simulated proof z, which is provided by the sim- 
ulator S and a real proof z as implied by the NIZK security experi- 
ment, it constructs the following ballots for voters V, and V}. It sets 
zo = Compute((Co, Cj, ... » Caa 8°, (eas z; =x, and constructs the 
corresponding ballots bp, b4. Then it picks a random bit f and gives A 
the ballot b,. If A can distinguish between the two cases, then 3 breaks 
the zero-knowledge property of the underlying QAP system. 

This is not possible, however, as was shown in [37]. Hence under 
the q-PDH and d-PKE assumptions, our voting scheme instantiated with 
the QAP defined in Section 5.4 is sound and zero knowledge. 


6.1.2. Other real world attacks 

We close this section by summarizing a number of real-world attacks 
our protocol defends against. 

In a randomized ballot attack, an adversary coerces a voter to submit 
a randomly composed ballot. While both the attacker and the voter have 
no idea about which candidate this voter casts the ballot for, the purpose 
of this attack is to nullify the ballots submitted by the voter. This attack 
does not work in our system since the voter cannot bypass the 7R nor 
submit an invalid ballot as explained in Remarks 2 and 3 above. 

In a ballot buying attack, the adversary asks for proof that the voter 
complied and voted as instructed. This is prevented in our system since 
the randomness r used to produce the commitments during registration 
and the proofs in the voting phase is never revealed. Thus nothing can 
link the ballot to the identity of the voter. 

In a credential leaking attack, an attacker can force the voter to give 
away her secret credentials. The purpose of this attack is either to al- 
low the coercer vote on behalf of the user, or find out what the user 
voted for. This attack is also prevented by our system since the actual 
ballot posted by the user is not linked to her private key used to sign her 
commitment in the registration phase. A more applicable attack is for 
the coercer to ask for the voter’s token randomizer. We treat this attack 
below. 

What if attacker asks for the user’s token randomizer? A coercion-free 
system is one in which a voter deceives an adversary into believing she 
behaved as instructed, even if she was asked to reveal her secret keys or 
vote in a particular way. In our case, the analogue of giving away secret 
keys would be to hand-over the token randomizer. To defend against this 
hand-over attack, we suggest a simple modification to T R’s functional- 
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ity. An implicit assumption here is that coercion takes place remotely, 
i.e. the adversary does not continuously watch over the shoulder of a 
voter, monitor her hard-drive, etc. Hence the voter has a moment of 
privacy (see also [7] for a similar assumption). 

In particular, we let the voter specify a vote v that will be locked 
in the 7R’s state. Then during the voting stage, even if the user (or 
the coercer) specifies a different vote v’, operation 7R.Ballot(v’) will 
result in posting the ballot (s, Ex(v), z) to the blockchain. This ballot 
remains unlinkable and the coercer cannot tell what the TR posted to 
the blockchain. 

Locking a vote v can occur any time after registration. The user 
interacts with the 7R as if she was ready to vote. However, if the 
TR’s internal counter signifies that the voting stage has not yet 
begun, the value v is stored internally and becomes a locked vote. 
This locked vote is then released when voting is allowed. As the 
TR already has the capability of internally storing secret values (re- 
call operational assumption TRA-2), this functionality can easily be 
supported. 


6.2. Efficiency aspects 


One important aspect of our system is that tallying has only a linear 
overhead with respect to number of voters n (as a comparison the system 
in [7] requires O(n?) work). This is due to the fact that the encrypted 
votes in ballots and the keys to open them bear the same identifier s (the 
serial used in the initial commitment). Hence tallying and producing the 
final result is a very efficient procedure. 

Additionally, the characteristics of the proof system for arithmetic 
circuits developed in [35] translate directly to our voting system. 
Nonetheless, significant performance gains can be achieved by main- 
taining the voter commitments in a Merkle tree instead of an explicit list 
Lom (the idea was used in the Zerocash implementation [23] for anony- 
mous Bitcoin payments). Doing so, reduces the time and space complex- 
ity from linear in the size of Leom to just logarithmic. Additionally, the 
NP statement used in the QAP construction of knowing the value r of one 
of the commitments C; maintained in L,,,, now becomes “I know r such 
that C; appears as a leaf in a Merkle tree with root r.” This modification 
increases exponentially the number of users (and their commitments) 
that can be supported by the system. 

The above, together with the state-of-the-art implementation of zk- 
SNARKs for arithmetic circuits results in a prover (the token random- 
izer’s) running time of a few minutes and a proof verification to just 
a few milliseconds. In particular, the findings in [23] show that a 
proof can be generated in under 3 minutes in a single threaded 2.7GHz 
CPU. Verifying a proof takes less than 9ms, while proof size is re- 
stricted to 288 bytes. Thus, considering the auditing part of the pro- 
tocol, a verifier has to validate the proof z and then use the key 
K to decrypt Ex(v). Both operations take time in the order of a few 
milliseconds on commodity hardware, so verification is minimal per 
vote. 

Perhaps it is more instructive to consider the communication over- 
head of our protocol. During the actual voting phase, the user sends (s, 
E,(v), x), where s is a random number of size 128 bits. Assuming the 
ballot is a Yes/No answer, E,(v) might as well fit in another 128 bits. 
Hence most of the overhead comes from the proof z which is bounded 
by 288 bytes. In the post-voting phase, the symmetric key K is then 
released which together with s contribute another 256 bits. Hence the 
communication overhead is minimal. 

From an implementation point of view, Hyperledger Fabric [39] can 
be used to implement the consortium blockchain needed for voting. In 
the next section, we argue that public blockchains built around a cryp- 
tocurrency such as Bitcoin are not suitable for voting for two main rea- 
sons: cost incurred to handle transactions due to mining fees, but most 
importantly, low throughput. Indeed, the Bitcoin blockchain can only 
process between 3-7 transactions per second, so its use is not advised 
for large scale elections in which millions of votes have to be submitted. 
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On the other hand, Hyperledger Fabric is an open-source sys- 
tem suitable for deploying and operating permissioned or consor- 
tium blockchains. When a vote is submitted into the system, a pre- 
defined endorsement policy is used to specify the peers that are 
necessary for endorsement; for example “five out of nine” organiza- 
tions must check the proof z of a submitted ballot and then sign 
the transaction. Once the transaction is validated, it is appended 
to the blockchain ledger and can be verified by any interested 
party. 

In their seminal paper [39], Androulaki et al. report a series of 
experiments that measure the transaction throughput, where the av- 
erage transaction size is in the order of 3 to 4 kbytes. It has been 
shown in this work that more than 3500 transactions can be pro- 
cessed per second (even extended to 20000tps in [40]), making Hy- 
perledger Fabric a viable choice for large scale elections. As in our 
case the transaction size is in the order of 300 bytes, we expect 
even larger throughputs than those reported in the aforementioned 
works. 

The above numbers suggest the practicality of our system and its use 
in large-scale elections. Our system does not require any heavy compu- 
tational power on behalf of the talliers since the only important opera- 
tion required to produce the final tally is verifying proofs in submitted 
ballots. Additionally, the communication overhead is minimal. Hence 
our system remains verifiable in a strong sense as anyone can check the 
validity of the election outcome. 


7. Discussion 


On the use of Blockchains for Voting All voting systems assume the 
existence of a bulletin board (BB), an append-only broadcast channel 
where ballots or other data get posted, without however specifying how 
this can be implemented. In real life, the bulletin board would have 
the form of website maintained by the election authorities, where data 
appear for public use, after being replicated to various storage servers 
to protect against accidental failures. 

In an end-to-end verifiable voting system, the main role of the bul- 
letin board is to ensure the fairness and correctness of the election pro- 
cess. To meet these objectives, bulletin boards must have a number of 
desirable properties, such as: 


e They must be distributed to withstand DOS attacks and accidental 
failures. 

° They must support the chronological logging of events. 

° They must be integrity protected to avoid manipulation attacks such 
as adding, removing or altering posted data. 

* They should be verifiable, i.e. that information posted is authentic. 


In real life, however, bulletin boards seldom satisfy these properties; 
election authorities control the bulletin board so they can add/remove 
information or even censor messages to be published. Consider, for 
example, the extreme case where authorities want to know what Al- 
ice voted for. They can simply replace all other ballots in the bul- 
letin board by encryptions of valid votes and then during tallying 
the preference of Alice will be revealed. What this “attack” demon- 
strates is that you cannot expect to have full privacy when bulletin 
boards are controlled by election authorities. Essentially, all protocols 
based on the use of BBs pre-suppose that election authorities can be 
trusted. 

The answer to “whether a blockchain is really necessary” is not clear. 
In principle, a bulletin board can be used instead considering the trust 
assumptions mentioned previously. But currently, the blockchain is the 
best implementation we have for a bulletin board [41]. It is widely dis- 
tributed, it is maintained by a collection of entities (not necessarily af- 
filiated with election authorities) which are incentivized to include all 
posted transactions, in a highly consistent manner. 

Use of a public blockchain comes with a number of disadvantages 
too, the most important one being that every transaction requires a 
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fee. So, who is going to pay for this? The election authorities may 
give each user a small amount but nothing prevents the user from 
taking the money and spent it elsewhere. Even if users are equipped 
during registration with blindly signed tokens that can be exchanged 
with ballots, such transactions still require a small fee. Another dis- 
advantage is throughput. A public blockchain like the one used by 
the Bitcoin network processes one transaction every few seconds, so it 
would take many days to handle the load generated by a large scale 
election. 

A solution to the above might be the use of permissioned blockchains. 
A blockchain of this kind is controlled by a group of nodes that deter- 
mine who can transact on the blockchain and who can serve the net- 
work by extending the chain with new blocks. That blockchain will 
not require a fee if a transaction is posted by a legitimate voter. An- 
other variant, a consortium blockchain might be closer to the needs 
of a democratic election. It is a “partially decentralized” blockchain 
[42], where the consensus process is controlled by a pre-selected set of 
nodes. Consider a consortium of 9 local and international institutions, 
in which 5 must sign every block in order for the block to be added 
to the blockchain. The right to read the blockchain can be public or 
restricted to the participants. These blockchains would process trans- 
actions at a greater rate, thus serving the needs of real-life elections. 
They would also be more resistant to spam and DoS attacks as they 
could easily filter transactions. They would, however, re-introduce trust 
in the authorities running these blockchain, hence the need for impartial 
observers.’ 


8. Conclusions 


As existing blockchain voting systems cannot provide the compre- 
hensive list of security features needed for secure elections, we have pro- 
posed a blockchain-based voting scheme that ensures voter privacy with 
minimal involvement on the user side. Our protocol uses the blockchain 
as an infrastructure for universally verifiable elections along with a num- 
ber of cryptographic primitives that can be used to achieve all basic 
properties expected from secure election schemes. Coercion resistance 
(and hence receipt-freeness) is achieved by means of a randomizer to- 
ken whose purpose is to act as a black-box on behalf of the voter. Ad- 
ditionally, no complicated operations like re-voting, managing fake cre- 
dentials, or lying to the coercer are expected from the user while no 
trust is placed on election authorities; even if the adversary corrupts 
talliers, ballots cannot be forged. Finally, the protocol is scalable and 
has linear tallying overhead which makes it practical for large-scale 
elections. 
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